Subject: Proposed Update to TRS Architecture

From: "Roy Brabson (254-7332 (T/L 444))" <[email-masked]>
Date: Thu, 6 Oct 94 15:40:04 EDT

> One solution to the problem might be to prevent routing through a
> TG when its mirror TG (ie. the same TG viewed in the opposite direction) is
> marked as inactive (or is not present in the network topology).
> Unfortunately, this falls down on two grounds:
>
>   - It would hamper the use of unidrectional auto-activatable links, and
>     links which support predefined TG numbers.
>
>   - It does not solve all occurrences of the problem. Eg. in the following
>     network:
>
>      NNB---VRN1
>       |     |
>       |     |
>      NNC---NNA
>       |     |
>       |     |
>      NND---VRN2
>
>     If NNA is shut down, and NND again tries to establish a session to NNA
>     then it may try to route NND->VRN2->NNA->VRN1->NNB, entirely across
>     bidirectional TGs.

Some IBM products (VTAM and CM/2 come to mind immediately) include the
check for bi-directional TGs when calculating an RSCV.  Only nodes which
are known to have only unidirectional TGs, such as ENs, are excluded
from this check.  It solves the problem with a NN leaving the topology
database when it has connections to non-VRNs.

As for VRNs, APPN architecture includes processing to cause invalid
connections to be deleted.  Page 9-122 of the CS chapter of the APPN
Node Reference shows CS sending a TG_UPDATE to TRS to report a TG through
a VRN to a real adjacent node as being inactive.  This is done because
the adjacent node may be inactive and its connections to the VRN may
not have been reported inactive.  The node which attempted to activate
the connection to the adjacent node declares the TG from the adjacent
node to the VRN to be inactive and generates a TDU on behalf of the
adjacent node.  Not completely dynamic in that the particular session
initiation request will fail, but since the TG is now inactive subsequent
session initiation requests will succeed.

> Change TRS route-calculation so that any network node which is no longer
> reachable by CP-CP sessions (ie. the local node cannot build a CP-CP session
> route to the remote node) has infinite weight.
>
> This means that it will become invalid to route sessions through any
> node which is not within the CP-CP session mesh.

This seems to be a reasonable proposal, as long as it remains an option
for products to implement.  The CPU consumption to build/cache and
query a complete CPSVCMG tree may be too much for smaller boxes.

Checking for bi-directional TGs and removing invalid connections to VRNs
for other nodes seems to solve the problems with less CPU usage.
However, a single session initiation request will fail for each VRN the
inactive node had been connected to in order to clean up the TRS
database.

Roy Brabson